Merge version 6.10.2-2+rpi1 and 6.10.2-3 to produce 6.10.2-3+rpi1

Merge qt6-tools (6.10.2-3) import into refs/heads/workingbranch

Look for zstd before Clang

Last-Update: 2025-07-19
Forwarded: not-needed

The story is more or less the following:
- LLVM ships its own Findzstd cmake find module from 16; this module defines
  2 targets: zstd::libzstd_shared and zstd::libzstd_static
- libzstd ships a cmake config module that defines 3 targets:
  zstd::libzstd_shared, zstd::libzstd_static, and zstd::libzstd
- the libzstd config module assumes that if one target is defined, all of them
  are, as if the config module itself was already run (i.e. multiple
  "find_package(zstd)" in a cmake project)
- in qttools, Clang is searched first, which in turns requires LLVM, and then
  libzstd

More details here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073480#47

As workaround, look for libzstd before Clang: this way the proper zstd cmake
targets are defined, and the Findzstd cmake find module shipped with LLVM will
use them just fine without redefining them.

This should most likely be fixed on LLVM side.

Gbp-Pq: Name cmake-find-zstd-before-clang.diff

qt6-tools (6.10.2-3) unstable; urgency=medium

  [ Patrick Franz ]
  * Remove kernel version from build artifacts to ensure reproducible
    builds.
  * Bump Standards-Version to 4.7.4 (no changes needed).
  * Remove the Breaks+Replaces for versions older than oldstable.

[dgit import unpatched qt6-tools 6.10.2-3]

Import qt6-tools_6.10.2-3.debian.tar.xz

[dgit import tarball qt6-tools 6.10.2-3 qt6-tools_6.10.2-3.debian.tar.xz]

Merge version 6.9.2-5+rpi1 and 6.10.2-2 to produce 6.10.2-2+rpi1

Merge qt6-tools (6.10.2-2) import into refs/heads/workingbranch

Look for zstd before Clang

Last-Update: 2025-07-19
Forwarded: not-needed

The story is more or less the following:
- LLVM ships its own Findzstd cmake find module from 16; this module defines
  2 targets: zstd::libzstd_shared and zstd::libzstd_static
- libzstd ships a cmake config module that defines 3 targets:
  zstd::libzstd_shared, zstd::libzstd_static, and zstd::libzstd
- the libzstd config module assumes that if one target is defined, all of them
  are, as if the config module itself was already run (i.e. multiple
  "find_package(zstd)" in a cmake project)
- in qttools, Clang is searched first, which in turns requires LLVM, and then
  libzstd

More details here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073480#47

As workaround, look for libzstd before Clang: this way the proper zstd cmake
targets are defined, and the Findzstd cmake find module shipped with LLVM will
use them just fine without redefining them.

This should most likely be fixed on LLVM side.

Gbp-Pq: Name cmake-find-zstd-before-clang.diff

qt6-tools (6.10.2-2) unstable; urgency=medium

  * Upload to unstable.

[dgit import unpatched qt6-tools 6.10.2-2]

Import qt6-tools_6.10.2-2.debian.tar.xz

[dgit import tarball qt6-tools 6.10.2-2 qt6-tools_6.10.2-2.debian.tar.xz]

Import qt6-tools_6.10.2.orig.tar.xz

[dgit import orig qt6-tools_6.10.2.orig.tar.xz]

Merge qt6-tools (6.9.2-5+rpi1) import into refs/heads/workingbranch

Look for zstd before Clang

Last-Update: 2025-07-19
Forwarded: not-needed

The story is more or less the following:
- LLVM ships its own Findzstd cmake find module from 16; this module defines
  2 targets: zstd::libzstd_shared and zstd::libzstd_static
- libzstd ships a cmake config module that defines 3 targets:
  zstd::libzstd_shared, zstd::libzstd_static, and zstd::libzstd
- the libzstd config module assumes that if one target is defined, all of them
  are, as if the config module itself was already run (i.e. multiple
  "find_package(zstd)" in a cmake project)
- in qttools, Clang is searched first, which in turns requires LLVM, and then
  libzstd

More details here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073480#47

As workaround, look for libzstd before Clang: this way the proper zstd cmake
targets are defined, and the Findzstd cmake find module shipped with LLVM will
use them just fine without redefining them.

This should most likely be fixed on LLVM side.

Gbp-Pq: Name cmake-find-zstd-before-clang.diff

upstream_llvm21

Gbp-Pq: Name upstream_llvm21.diff

qt6-tools (6.9.2-5+rpi1) forky-staging; urgency=medium

  * Skip dh_missing.

[dgit import unpatched qt6-tools 6.9.2-5+rpi1]

Import qt6-tools_6.9.2-5+rpi1.debian.tar.xz

[dgit import tarball qt6-tools 6.9.2-5+rpi1 qt6-tools_6.9.2-5+rpi1.debian.tar.xz]

Merge qt6-tools (6.9.2-5) import into refs/heads/workingbranch

Look for zstd before Clang

Last-Update: 2025-07-19
Forwarded: not-needed

The story is more or less the following:
- LLVM ships its own Findzstd cmake find module from 16; this module defines
  2 targets: zstd::libzstd_shared and zstd::libzstd_static
- libzstd ships a cmake config module that defines 3 targets:
  zstd::libzstd_shared, zstd::libzstd_static, and zstd::libzstd
- the libzstd config module assumes that if one target is defined, all of them
  are, as if the config module itself was already run (i.e. multiple
  "find_package(zstd)" in a cmake project)
- in qttools, Clang is searched first, which in turns requires LLVM, and then
  libzstd

More details here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073480#47

As workaround, look for libzstd before Clang: this way the proper zstd cmake
targets are defined, and the Findzstd cmake find module shipped with LLVM will
use them just fine without redefining them.

This should most likely be fixed on LLVM side.

Gbp-Pq: Name cmake-find-zstd-before-clang.diff

upstream_llvm21

Gbp-Pq: Name upstream_llvm21.diff

qt6-tools (6.9.2-5) unstable; urgency=medium

  [ Patrick Franz ]
  * Actually use LLVM 21.

[dgit import unpatched qt6-tools 6.9.2-5]

Import qt6-tools_6.9.2-5.debian.tar.xz

[dgit import tarball qt6-tools 6.9.2-5 qt6-tools_6.9.2-5.debian.tar.xz]

Import qt6-tools_6.9.2.orig.tar.xz

[dgit import orig qt6-tools_6.9.2.orig.tar.xz]

Merge qt6-tools (6.8.2-5) import into refs/heads/workingbranch

Look for zstd before Clang

Last-Update: 2024-07-17
Forwarded: not-needed

The story is more or less the following:
- LLVM ships its own Findzstd cmake find module from 16; this module defines
  2 targets: zstd::libzstd_shared and zstd::libzstd_static
- libzstd ships a cmake config module that defines 3 targets:
  zstd::libzstd_shared, zstd::libzstd_static, and zstd::libzstd
- the libzstd config module assumes that if one target is defined, all of them
  are, as if the config module itself was already run (i.e. multiple
  "find_package(zstd)" in a cmake project)
- in qttools, Clang is searched first, which in turns requires LLVM, and then
  libzstd

More details here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073480#47

As workaround, look for libzstd before Clang: this way the proper zstd cmake
targets are defined, and the Findzstd cmake find module shipped with LLVM will
use them just fine without redefining them.

This should most likely be fixed on LLVM side.

Gbp-Pq: Name cmake-find-zstd-before-clang.diff

qt6-tools (6.8.2-5) unstable; urgency=medium

  * Team upload.
  * Update symbols files from the logs of buildds.
  * Replace the unversioned llvm build dependency with llvm-19, following the
    other LLVM/clang versioned build dependencies.
  * Enable qdoc also on powerpc, ppc64, and x32.

[dgit import unpatched qt6-tools 6.8.2-5]

Import qt6-tools_6.8.2-5.debian.tar.xz

[dgit import tarball qt6-tools 6.8.2-5 qt6-tools_6.8.2-5.debian.tar.xz]

Import qt6-tools_6.8.2.orig.tar.xz

[dgit import orig qt6-tools_6.8.2.orig.tar.xz]

Fix build with system litehtml

CMake errors out when using system litehtml (which depends on gumbo) due being
unable to set definitions for libraries not built by the Qt6 Tools project:

 CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Qt6/QtFlagHandlingHelpers.cmake:171 (target_compile_definitions):
   Cannot specify compile definitions for target "litehtml" which is not built
   by this project.
 Call Stack (most recent call first):
   src/assistant/CMakeLists.txt:34 (qt_internal_set_exceptions_flags)

 CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Qt6/QtFlagHandlingHelpers.cmake:190 (get_target_property):
   get_target_property() called with non-existent target "litehtml".
 Call Stack (most recent call first):
   src/assistant/CMakeLists.txt:35 (qt_disable_warnings)

 CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Qt6/QtFlagHandlingHelpers.cmake:190 (get_target_property):
   get_target_property() called with non-existent target "gumbo".
 Call Stack (most recent call first):
   src/assistant/CMakeLists.txt:37 (qt_disable_warnings)

Also, litehtml > 0.5 reorganises the headers into a litehtml sub-directory
(this build is with exactly litehtml 0.5+git20211028, the same version found
in Qt6 Tools source code). Fix the build by removing attempts to set Qt defs
for litehtml/gumbo and by using the new path to the primary header.

Gbp-Pq: Name fix-build-with-system-litehtml.patch

qt6-tools (6.4.2~rc1-2) unstable; urgency=medium

  [ Patrick Franz ]
  * Upload to unstable.

[dgit import unpatched qt6-tools 6.4.2~rc1-2]

Import qt6-tools_6.4.2~rc1-2.debian.tar.xz

[dgit import tarball qt6-tools 6.4.2~rc1-2 qt6-tools_6.4.2~rc1-2.debian.tar.xz]

Import qt6-tools_6.4.2~rc1.orig.tar.xz

[dgit import orig qt6-tools_6.4.2~rc1.orig.tar.xz]